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CONTRACT CHANGE AGREEMENT 

This Contract Change Agreement (“Agreement” or “CCA”) is entered into by and between 
ERG Transit Systems (USA) Inc, a California corporation and wholly owned subsidiary of 
ERG Limited, an Australian corporation (hereinafter referred to as the “Contractor”), and each 
of the following seven public transportation agencies (hereinafter referred to individually as an 
“Agency” or collectively as the “Agencies"): 

1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area (“Pierce Transit”) 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett (“Everett”) 

7. State of Washington, acting through the Washington State Department of 
Transportation, Washington State Ferries Division ("WSF") 

RECITALS 

A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract 
#229944 (“Contract”) to implement a Regional Fare Coordination System (“RFC System” or 
“RFCS”) to establish a common fare system utilizing smart card technology. The Contractor is 
responsible for the development, implementation, operation and maintenance of the RFC 
System as specified in the Contract. 

B. The Parties have executed several Contract Amendments and Change Orders since 
execution of the original Contract. 

C. Since the inception of the Project the Contractor has been developing successively 
more detailed design documents in an effort to achieve the Project Milestone of Final Design 
Completion. 

D. The Agencies have actively participated in the Contractor’s design process by 
reviewing design documents, meeting with the Contractor's representatives and providing 
detailed information about the Agencies' existing and planned facilities, vehicles, systems, 
business rules, fare policies and other matters related to the RFCS. 
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E. The design process has extended beyond the time allocated for design activities in the 
last-approved Project Schedule (“CO#4 Project Schedule”). Further, upon more detailed 
planning, it appears that more time than was allocated in said CO#4 Project Schedule will be 
necessary for the completion of post-design implementation activities. 

F. Adding time to create a reasonably achievable Project Schedule through Completion 
of Final Design, Beta Test Acceptance and Full System Acceptance has and will result in 
damages and additional costs for both the Contractor and the Agencies. 

G. The causes of the delay to-date are varied and subject to disagreement between the 
Contractor and the Agencies, but all acknowledge that the design process has been more 
complex and challenging than anticipated. 

H. In addition, disagreements between the Contractor and the Agencies have arisen 
during the design process over interpretations of the Contract requirements, with regard to 
both design and implementation matters. 

I. Disagreements between the Contractor and Agencies have also arisen over what 
activity durations would constitute a reasonably achievable Project Schedule going forward. 

J. Notwithstanding these disagreements, the Contractor has continued to perform design 
and development activities and the Contractor and the Agencies have continued to work 
cooperatively in good faith on the design process and the planning for implementation. 

K. The Parties have asserted claims and potential claims against each other arising from 
the delays to the Project Schedule and other Contract issues but, without admitting any 
liability, desire to compromise and settle their respective claims and potential claims. 

L. The Contractor and the Agencies have negotiated and agreed upon the terms and 
provisions of this Agreement in order to: continue making progress on RFCS design and 
implementation; establish a new Project Schedule that allows all Parties to effectively plan for 
future RFCS implementation tasks; resolve issues that could cause further delay to the 
Project if not resolved; defer resolution of certain design issues as specified in this 
Agreement; and avoid the uncertainties and inconvenience of litigation and the delays and 
expenses attendant thereto. 


TERMS 

NOW, THEREFORE, in consideration of the mutual covenants contained herein, the 
sufficiency of which is hereby acknowledged, Contractor and the Agencies agree as follows: 

1.0 Definitions 

1.1 “Damages” means any direct and indirect damages, including but not limited to 
increased direct and indirect costs, overhead, losses, delayed revenue receipts, loss of use, 
loss of time, loss of goodwill, inconvenience, commercial loss, lost profits or anticipated 
business savings, wasted management time or other indirect, incidental or consequential 
damages. 

1.2 “Future Delay(s)” means failure to timely complete a task with a "Finish" date after 
August 8, 2005, as specified in the New Project Schedule attached to this Agreement. 
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1.3 “Past Delay(s)” means delay experienced prior to and through August 8, 2005, the 
date of execution of this Agreement. 

1.4 “Schedule Change” means the changes to the Project Schedule that are 
encompassed in the New Project Schedule attached to this Agreement, including (a) any 
Past Delays; (b) any changes in the time for the total Project Schedule, each Project and 
Payment Milestone and/or each listed task or activity; and (c) the past, present and future 
effects of Past Delays and said changes in the Project Schedule, including but not limited to 
any impacts, cumulative impacts, ripple effects, use of different means or methods, increased 
levels of effort, added resources, changed sequences, compressions, accelerations, 
demobilizations, inefficiencies, disruptions and other effects on the Contractor of same. The 
term “Schedule Change” does not include Future Delays and the impacts of Future Delays. 


2.0 New Project Schedule 

2.1 The Agencies and the Contractor hereby agree, without further execution, to amend 
the Contract as provided in Amendment Twelve to the Contract, a copy of which is attached 
hereto as “CCA-Attachment A.” Among other things, said Amendment Twelve establishes a 
New Project Schedule. 

2.2 The Contractor, for and on behalf of itself, its parent corporation and their 
subcontractors, suppliers and any other person or entity supplying work or materials to the 
RFCS Project through them, forever and unconditionally releases and forever discharges the 
Agencies, each of them and their respective officials, employees, contractors and agents, 
from any and all claims, demands, suits, actions, Damages, expenses (including attorneys” 
fees and related costs whether or not litigation is commenced) and liabilities of any kind 
(“Contractor Claims”), known or unknown, that have arisen, or will arise in the future, as a 
result of the Schedule Change and actual or constructive changes that occurred or began 
prior to the date of this Agreement. Without limiting the foregoing, this release and discharge 
shall include Contractor Claims for adjustment of time and compensation asserting that the 
Schedule Change caused or contributed to Damages. Provided, however, this release and 
discharge does not apply to Contractor Claims based on the non-delay issues referred to in 
Section 5.0 or on a Future Delay and the impacts thereof in the performance of the New 
Project Schedule. 

2.3 The Agencies forever and unconditionally release and forever discharge the 
Contractor, its parent corporation and their officers, employees, suppliers, contractors and 
agents, from any and all claims, demands, suits, actions, Damages, expenses (including 
attorneys” fees and related costs whether or not litigation is commenced) and liabilities of any 
kind (“Agency Claims”), known or unknown, that have arisen, or will arise in the future, as a 
result of the Schedule Change. Without limiting the foregoing, this release and discharge 
shall include Agency Claims asserting that the Schedule Change caused or contributed to 
Damages. Provided, however, this release and discharge does not apply to Agency Claims 
based on the non-delay issues referred to in Section 5.0 or on a Future Delay and the 
impacts thereof in the performance of the New Project Schedule. 
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2.4 As provided in the Contract, the Agencies’ approval of the New Project Schedule shall 
not constitute approval or acceptance of the Contractor's means, methods, sequencing, logic, 
order, precedence and succession of activities or Contractor’s ability to complete the Work in 
a timely manner. This release and discharge does not apply to, and the Contractor remains 
responsible for, any mistakes, errors or omissions in any schedule, including, but not limited 
to, mistakes, errors or omissions of logic, order, precedence, and duration, except to the 
extent that any such mistakes, errors or omissions arise from information provided by the 
Agencies and except to the extent Contractor’s performance is otherwise excused under the 
terms of the Contact. 

3.0 Amendments to Division I 

Amendment Twelve to the Contract, as adopted under Section 2.1 above, amends the 
following sections of Division I of the Contract. 

Section 3.1-11 Security of the RFC System 

Section 3.1-13 System Backup and Disaster Recovery/Business Resumption Plan. 

4.0 Change Orders to Division II 

The Agencies and the Contractor hereby agree, without further execution, to change Sections 
6.11-11.1.2.3 and 6.11-11.4 as provided in Change Order No. 13, a copy of which is attached 
hereto as “CCA-Attachment B”. 

5.0 Resolution of Deferred Issues 

The Agencies and the Contractor acknowledge that issues remain concerning certain design 
elements. The Parties agree to cooperatively and in good faith attempt to resolve, by the end 
of September 2005, the "Deferred RFCS Design Issues" attached hereto as "CCA- 
Attachment C." In the event said issues are not resolved by September 30, 2005, either the 
Contractor or the Agencies may forward the issue to the DRB as a "dispute" under Section 
3.1-34. 


6.0 Other Terms and Conditions 

6.1 The Contractor is responsible for negotiating and satisfying any and all subcontractor 
claims arising out of the Schedule Change on a full and final basis and shall defend, 
indemnify and hold harmless the Agencies from all such claims. The Agencies are 
responsible for negotiating and satisfying any and all claims by suppliers or other contractors 
of the Agencies that arise out of the Schedule Change on a full and final basis and shall 
defend, indemnify and hold harmless the Contractor from all such claims. 

6.2 The release and discharge provided by the Contractor and the Agencies under this 
Agreement is each made in compromise and settlement and shall not be construed as an 
admission of liability. 

6.3 Except as provided in Section 2.0 for Schedule Changes, nothing in this Agreement 
shall be construed as a waiver, release or discharge of any party's rights under the Contract 
or at law with regard to an other party's performance of its obligations under the Contract. 
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6.4 Except as expressly provided in this Agreement and its attachments, or in other 
executed Amendments and Change Orders, the provisions of the Contract shall remain in full 
force and effect without change, including but not limited to the provisions of Section 3.1-26, 
“Project Schedule for System Development Work”, Section 3.1-27, “Progression of System 
Development Work”, Section 3.1-33. “Contract Claims”, and Section 3.1-34, “Dispute Review 
Board.” 
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IN WITNESS WHEREOF, the authorized representatives of the Contractor and the Agencies have 
signed their names in the spaces provided below. 

ERG Transit Systems (USA), Inc. 

By:_ 

Its:_ 

Date: _ 


Central Puget Sound Regional Transit 
Authority 

By:_ 

Its:_ 

Date:_ 

King County 

By:_ 

Its:_ 

Date:_ 

Pierce County Public Transportation 
Benefit Area 

By:_ 

Its:_ 

Date: _ 

Washington State Ferries, Washington 
State Department of Transportation 

By:_ 

Its:_ 

Date: _ 


City of Everett 

By:_ 

Its:_ 

Date:_ 

Kitsap County Public Benefit Transportation 
Area 

By:_ 

Its:_ 

Date:_ 

Snohomish County Public 
Transportation Benefit Area 

By:_ 

Its:_ 

Date:_ 
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CCA- Attachment A 


Amendment Twelve to the Contract for the Design, Implementation, Operation and 
Maintenance of the Regional Fare Coordination System 

This Amendment Twelve to the Contract for the Design, Implementation, Operation and 

Maintenance of the Regional Fare Coordination System is entered into this_day of 

_, 2005, by and between ERG Transit Systems (USA) Inc, a California 

corporation and wholly owned subsidiary of ERG Limited, an Australian corporation, 
(hereinafter referred to as the "Contractor") and each of the following seven public 
transportation agencies (hereinafter referred to individually as an "Agency" or collectively as 
the "Agencies"): 

1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area ("Pierce Transit") 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett ("Everett") 

7. State of Washington, acting through the Washington State Department of 
Transportation, Washington State Ferries Division ("WSF") 

Recitals 


A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract 
#229944 ("Contract") to implement a Regional Fare Coordination System ("RFC System") to 
establish a common fare system utilizing smart card technology. The Contractor is 
responsible for the development, implementation, operation and maintenance of the RFC 
System as specified in the Contract. 

B. In order to establish a new Project Schedule and resolve potential claims and other 
issues, the Agencies and the Contractor have entered into that certain Contract Change 

Agreement dated_, 2005. This Amendment Twelve is attached to, and adopted by, the 

Agencies and the Contractor as part of said Contract Change Agreement. 


Amendment 


NOW, THEREFORE, in consideration of the mutual covenants contained herein, the 
sufficiency of which is hereby acknowledged, the Agencies and the Contractor hereby agree 
to amend the Contract as follows: 

Section 1.0 New Project Schedule 
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1.1 Exhibit 8, "Project Schedule," is hereby replaced in its entirety by the new Project 
Schedule enclosed herewith in CD format. Provided, however, the Parties acknowledge that 
this new Project Schedule does not necessarily reflect actual start and/or finish dates that 
have occurred prior to this Amendment. (Note: The Parties agree that the New Project 
Schedule is not available at the time of signing of this Amendment but that it will be supplied 
by the Contractor in a form that is consistent with the Key Completion Date Summary 
attached per Section 1.2 below.) 

1.2 Attachment H to the Project Schedule, "Key Completion Date Summary," is hereby 
replaced in its entirety by the new Attachment H, attached hereto as CCA-Attachment A-l. 

Section 2.0 Security Audit 

Section 3.1-11, Security of RFC System," is hereby amended as follows: 

3.1-11 Security of RFC System 

11.1 Contractor shall maintain the security of the RFC System, including security for 
all computer systems, information and monetary transactions, in accordance with the 
professional standards of persons and firms with specialized knowledge, expertise and 
experience who are leading designers and providers of systems, software and 
hardware used in the automated smart card fare payment industry. Such security shall 
include, without limitation: (i) maintaining physical security of the RFC System, to 
ensure that no unauthorized person shall have access to the RFC System; (ii) creating 
firewalls, password protections, and other appropriate measures to protect against 
unauthorized access to the RFC System or to Customer information by Contractor's 
employees, Agency employees or third parties; (iii) protecting against penetration of 
security and manipulation of customer account data by Contractor's personnel, Agency 
personnel or third parties; and (iv) additional security measures as specified in the 
Services and Equipment Specifications in Divisions II and III. 

11.2 Contractor shall update its security procedures as technology and security 
threats evolve to provide security capabilities at all times that are in accordance with 
the professional standards of persons and firms with specialized knowledge, expertise 
and experience who are leading designers and providers of systems, software and 
hardware used in the automated smart card fare payment industry. 

11.3 Contractor shall have its security procedures and physical facilities audited by a 
qualified, nationally recognized firm, and Contractor shall take such actions as may be 
identified in such audit as necessary to comply with the professional standards of 
persons and firms with specialized knowledge, expertise and experience who are 
leading designers and providers of systems, software and hardware used in the 
automated smart card fare payment industry. The Contractor's initial security audit 
shall consist of the following tasks at a minimum: 

a. by September 30, 2005: a review of CDRL 31 with an assessment of its 
adequacy and conformance with industry best practices; a review and 
assessment of the Contractor's existing security measures at its facilities 
operating the Translink system; 
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b. by October 31, 2005: a detailed plan and description of the testing that will 
be conducted as specified in 11.3(c) below; 


c. as part of the RFCS System Integration Testing (scheduled for January, 
2006), intrusion and other testing activities as agreed by ERG and the 
Agencies. 

The Contractor shall complete a second audit no later than May 31, 2006 and then 
shall conduct such audits by May 31 annually thereafter. Subject to the confidentiality 
provisions of this Contract, Contractor shall direct the auditor to provide the Contract 
Administrator with a copy of the final report of such audit within fifteen (15) days after it 
is completed. 

11.4 The Contractor shall report to the Contract Administrator any unauthorized use of 
the RFC System or unauthorized disclosure of RFCS-related data within forty-eight 
(48) hours after the Contractor becomes aware of such use or disclosure. In such 
event, the Contractor shall take such further steps as may reasonably be requested by 
the Contract Administrator to prevent further unauthorized use of the RFCS or data 
related thereto. 

11.5 At all times, the Contractor shall maintain the security of the collection and 
clearinghouse operations in accordance with this Contract, applicable legal and 
regulatory requirements, and in accordance with the professional standards of persons 
and firms with specialized knowledge, expertise and experience who are leading 
designers and providers of systems, software and hardware used in the automated 
smart card fare payment industry. 


Section 3.0 System Backup and Disaster Recovery/Business Resumption Plan 

Section 3.1-13, System Backup and Disaster Recovery/Business Resumption Plan," is 
hereby amended as follows: 

13.1 In accordance with the Contract Document Requirements List provided in 
Section 6.11-11.6.1.1, the Contractor shall submit to the Contract Administrator a 
comprehensive System Backup and Disaster Recovery/Business Resumption Plan. 
The Plan shall include, but is not limited to, the following elements: 

a. A detailed explanation of protections in place at the central 
clearinghouse facility to protect against and mitigate the adverse impacts 
of power and/or communications failures, catastrophic events, or other 
disasters, including all on-site and remote data storage and backup 
procedures; 

b. A detailed explanation of the Contractor's compliance with the 
technical specifications for data backup and recovery provided in this 
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Contract including, but not limited to, Sections 6.11-5.2.8 Database 
Management, 6.11-8.2.3 Network Management, 6.111-1.4 Data Backup and 
Recovery, and 6.111-3.8 FTP - Additional Security; 

c. A detailed description of the Disaster Recovery Center (DRC) which 
the Contractor will set up and maintain as a back-up site for the central 
clearinghouse facility. The DRC shall be in a location as approved by the 
Agencies (such approval shall not to be unreasonably withheld or 
delayed) and is geographically separate from, and not subject to the 
same risks as, the location where the clearinghouse's production 
equipment is regularly operated. The description shall include: (i) the 
location of the facility; (ii) the number of anticipated personnel to be 
located at the facility should its full operation become necessary; (iii) how 
the facility will be mobilized and operated; and (iv) a schedule and 
description of periodic, complete tests of readiness for such facility. 

d. A detailed description of the tools, processes and procedures required 
to activate the Disaster Recovery Center. All tools, processes and 
procedures shall be provided to the entity responsible for facility 
activation; 

e. Whether the Contractor plans to contract with a third party to activate 
and operate the Disaster Recovery Center. Such provision of services 
by a third party shall be subject to the approval of the Agencies, which 
shall not be unreasonably withheld and shall require the third party to 
take reasonable steps to maintain the confidentiality of all software and 
data; and 

f. A detailed description of procedures to be followed by the Contractor 
in the event that a power and/or communications failure, catastrophic 
event, or other disaster occurs either locally in the Puget Sound region or 
at the Contractor's production serverjocation. Such procedures shall 
include a description of the conditions for Disaster Recovery Center 
activation, and shall describe specific activation processes. 

13.2 Not later than the date of commencement of the BETA Test, the Contractor shall 
have set up and rendered operational a facility in the Agency-approved location that is 
capable of replicating centralized services and data related to the operation of the RFC 
System. 

13.3 Contractor shall notify the Contract Administrator within four (4) hours of a power 
and/or communications failure, catastrophic event, or other disaster. 

13.4 In the event that a power and/or communications failure, catastrophic event, or 
other disaster prevents operations of the central clearinghouse facility and/or disrupts 
communications to the RFCS, the Contractor shall: 

a. Immediately and automatically place the RFCS components in off-line 
operation such that fare sales and collection can continue without 
interruption; 
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b. Within twenty-four (24) hours, activate the Disaster Recovery Center 
and provide all RFCS on-line and off-line functionality with the exception 
of second tier customer service. 

c. Within twenty-four (24) hours, provide Contractor-employed staff on¬ 
site to verify correct operation of the Disaster Recovery Center. Within 
this period the Contractor shall also assume on-going operation of the 
Disaster Recovery Center until such time as the central clearinghouse 
and full system operation is restored; and 

d. Within thirty (30) days, restore full clearinghouse and system 
operation. 
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CCA-Attachment A-l 


Attachment H Key Completion Date Summary 
(to be inserted here) 
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CCA - Attachment B 

REGIONAL FARE COORDINATION SYSTEM 
CHANGE ORDER NO. 13 

CONTRACTOR: ERG Transit Systems (USA) Inc. 

CONTRACT NUMBER: 229944 

This Change Order to Contract #229944 (“Change Order”) is executed as of_, by and between ERG 

Transit Systems (USA) Inc, a California corporation and wholly owned subsidiary of ERG Limited, an 
Australian corporation, (hereinafter referred to as the “Contractor”) and each of the following seven public 
transportation agencies (hereinafter referred to individually as an “Agency” or collectively as the “Agencies”): 


1. Central Puget Sound Regional Transit Authority ("Sound Transit") 

2. King County ("King County") 

3. Kitsap County Public Transportation Benefit Area ("Kitsap Transit") 

4. Pierce County Public Transportation Benefit Area (“Pierce Transit”) 

5. Snohomish County Public Transportation Benefit Area ("Community Transit") 

6. City of Everett (“Everett”) 

7. State of Washington, acting through the Washington State Department of Transportation, Washington 

State Ferries Division ("WSF") 


Background 

A. Effective April 29, 2003, each of the Agencies and the Contractor entered into Contract #229944 
(“Contract”) to implement a Regional Fare Coordination System (“RFC System”) to establish a common 
fare system utilizing smart card technology. The Contractor is responsible for the development, 
implementation, operation and maintenance of the RFC System as specified in the Contract. 

B. The Agencies and the Contractor desire to execute this Change Order No. 13 to modify the testing 
process provisions of the Contract to be consistent with the change to the Project Schedule of this same 
date. 


Agreements 


The Agencies and the Contractor hereby agree to the following changes to the Contract. 

1.0 Implementation Planning 

Section 6.II-11.1.2.3 is amended as follows: 

11.1.2.3 King County Metro 
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The following requirements shall apply to implementation of the RFCS (including Beta Test 
equipment, unless otherwise indicated) at King County Metro: 


(a) The Beta Test shall consist of equipment installed at only one base, to be specified 
by the Contract Administrator, and must include at least one CSO to test the 
integration of the KCM point of sale terminal with the new system. 

(b) On-site installation of equipment shall occur during the days and times as directed 
by KCM, and may occur on weekdays and/or weekends (Saturdays and Sundays). 

(c) No system start-up shall occur on the day of a seasonal service schedule change 
which usually occurs on the first Saturday in February, last Saturday in May, and 
the third Saturday in September. 

(d) King County Metro will replace their existing mobile data terminal (MDT) with the 
driver display unit (DDU) and radio control unit (RCU) supplied under this 
contract. 

(e) The driver display unit and radio control unit must be operational before the on¬ 
board equipment is installed. Not later than ten (10) days after FDR NAC, the 
Contractor shall deliver for the Contract Administrator's approval a DDU/RCU 
Integration Test Plan. As stated in the Project Schedule, the Contractor shall 
successfully complete, on at least two buses in Seattle with King County 
representatives present, the agreed-upon DDU/RCU Integration Test and 
demonstrate that the DDU and RCU will provide the required functionality at a 
satisfactory level for use in County revenue service. Said DDU/RCU Integration 
Test shall be performed, and the report of same provided to King County, in 
accordance with Section 6.II-11.4.8. 


(f) Implementation of the RFCS in King County shall be coordinated with the work of 
other contractors and the implementation of other on-board systems. Three devices, 
the Driver Display Unit (DDU - Section 6.III-6), the Radio Control Unit (RCU - 
Section 6.8.3), and the WDOLS (Section 6.III-7) are integral to King County’s on¬ 
board systems projects. These timelines are to support other projects and do not 
supercede equipment delivery requirements of the RFCS implementation set forth 
in Contract Section 6.II-11 System Implementation and the approved Project 
Schedule. These and other related devices shall be delivered as described below. 

i. By March 1, 2006, five (5) production (or pre-production, if production 
equipment not yet available) DDUs shall be delivered to King County. 
These will be used by King County and designated contractors to develop 
other on-board system devices and applications. 

ii. The DDU shall have the production hardware, operating system, user 
interfaces, and data interfaces, as well as the core application software 
required to operate the device, program and operate the keys and display, 
and create, send and receive messages to other devices. Full RCU-related 
functionality and the "home" screen will be provided. Full functionality of 
RFCS-specific application software will be provided to the extent then- 
available. 

iii. DDU software and documentation shall be provided such that application 
and interface development can proceed on the DDU and other on-board 
devices (by King County or designated contractors). 
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iv. By March 1, 2006, five (5) production (or pre-production, if production 
equipment not yet available) RCUs shall be delivered to King County. 

These RCUs shall have the production hardware, operating system, and 
data interfaces required to operate the devices. Final documentation shall 
be delivered. 

v. By March 1, 2006, five (5) production Wireless Data On-Off Load Systems 
(WDOLS - Section 6.III-7) on-board and bus antenna devices and one (1) 
production (or pre-production, if production equipment not yet available) 
Data Collection Systems (DACS - Section 6.III-12) shall be delivered to 
King County. These will be used to develop and test data transfer from the 
vehicle to the DACS. Both devices shall be supplied with the hardware, 
software and documentation required to conduct this development. Full 
functionality of RFCS and King County-specific functionality and 
application software will be provided to the extent then-available. 

vi. To the extent pre-production equipment must be provided to meet the above 
due dates, the Contractor shall provide production equipment as soon 
thereafter as it becomes available. 

(g) As stated in the Project Schedule, final production DDUs and RCUs shall be 
delivered in quantities to support the RFCS Beta test. Estimated quantities for both 
tests are included in Appendix A. 


2.0 Testing 

Section 6.II-11.4 is amended as follows: 

6.II-11.4 Testing Requirements 

11.4.1 Overview of Testing 

All of the components, subsystems and systems processes constituting the RFCS shall 
be tested individually and together to ensure that they meet the Contract requirements 
and provide a properly functioning system. The work under this section shall include all 
labor, materials, and support services required to completely inspect and test all 
hardware and software. 

In addition to the qualification, integration and other internal testing it performs, 
Contractor shall be responsible for the performance of all of the tests described below to 
satisfy the objectives of each testing phase as determined by the Contract 
Administrator. The Agencies and/or its associates shall oversee the performance of the 
tests described below. 

The following outlines the general testing sequence and describes the different testing 
stages: 


(a) Factory Acceptance Tests (FAT) 

Factory Acceptance Testing shall be performed to ensure that the supplied and 
developed components meet all functional and environmental requirements and 
specifications. Factory Acceptance Tests shall be performed on each type of 
equipment prior to it being delivered to any Agency. 
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For further details concerning the Factory Acceptance Tests refer to Section 

11.4.2. 


(b) System Integration Tests (SIT) 

System Integration Testing shall be performed to verify that subsystem 
components, when integrated together, meet the system level functional 
requirements and specifications. System Integration Testing is completed prior 
to onsite installation of the system except as otherwise provided in Section 

11.4.3. 

For further details concerning the System Integration Tests refer to Section 

11.4.3. 

(c) Installation Test 

Following onsite installation of the equipment, Installation Testing shall be 
performed. Installation Tests are used to determine if the equipment delivered 
to the installation site has been installed correctly and functions, component 
wise, to the requirements and specification. 

For further details concerning the Installation Tests refer to Section 11.4.4. 

(d) System Commissioning 

During the System Commissioning testing phase the installed and integrated 
system is verified to function according to the system wide requirements. 
System Commissioning is completed prior to placing the system into revenue 
service, both prior to the Beta Test and prior to the Full System Acceptance 
Test. 

For further details concerning the System Commissioning Test refer to Section 
11.4.5. 

(e) Beta Test 

The Beta Test phase begins when a subset of each Agency’s equipment is 
placed into revenue service. The Beta Test includes a subset of the systems and 
services to be provided for the full RFCS implementation. The objective of the 
Beta Test is to confirm the functional acceptability of the RFC systems and 
services under revenue service operation before implementing the full RFCS. 

For further details concerning the Beta Tests refer to Section 11.4.6. 

(f) Acceptance Testing 

Following successful completion and Agency approval of the Beta Test, full 
implementation of the RFCS will proceed. Acceptance testing will be 
performed on all equipment and services placed into revenue service to 
demonstrate the performance of the system as a whole. The completion of the 
Acceptance Testing will be contingent upon the system meeting specified 
performance levels. 

For further details concerning Acceptance Testing refer to Section 11.4.7. 
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The relationship of the specified test requirements up to completion of the Beta Test is 
shown in the flowchart provided in Figure II-11.4. 

The relationship of the specified test requirements up to completion of the Full RFCS 
Implementation is shown in the flowchart provided in Figure II-11.5. 
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Figure II-11.4 

Relationship Of Phase I Testing (Beta Test) 
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Figure II-11.5 

Relationship Of Phase II Testing 
(Full RFCS Implementation) 


Production 

Baseline 



11.4.2 Factory Acceptance Tests (FAT) 

The Contractor shall provide a comprehensive Factory Acceptance Test (FAT) program 
(CDRL 14) that shall consist of the following individual test programs: 

i. Functional Test 

ii. Environmental Test 

iii. Electromagnetic Interference Test 
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iv. Radiated Electromagnetic 

v. Human Factors Test 

(a) Each equipment type and all of its functions shall be subject to the FAT 
unless waived by the Contract Administrator. 

(b) One item of each equipment type shall be tested as specified in this 
Section 11.4.2 and the accepted Factory Acceptance Test Plan (CDRL 14). 

(c) If the Contractor can prove by certification of using authority, property, 
or independent testing organization that equipment manifestly similar to that 
specified here has been subjected to testing to the extent specified, the 
associated test may be waived, subject to the Contract Administrator’s 
approval. The Contractor shall submit independently verified tests to the 
Contract Administrator for approval at least sixty (60) days prior to the 
scheduled start date for the FAT. Whether a test is completed or waived by the 
Contract Administrator, the Contractor agrees, as also provided in Section 3.1-7, 
that it retains full responsibility to deliver System equipment and functions that 
comply with the Contract requirements. 

(d) Factory Acceptance Testing shall be performed in controlled, laboratory 
conditions at a Contract Administrator approved factory or independent 
facilities. 

11.4.2.1 Functional Test 

The purpose of this test shall be to demonstrate that for each RFCS equipment type, the 
functions specified throughout the Contract Documents, including all limiting 
conditions, shall be met. 

(a) The equipment shall be required to execute all hardware and software functions 
as detailed in these specifications and to meet the performance criteria 
requirements. 

(b) The Contractor shall be responsible for developing a functional test 
procedure that satisfactorily demonstrates all equipment functions and shall 
submit this test procedure to the Contract Administrator for approval thirty (30) 
days in advance of the test. 

(c) Each function specified shall be tested at least once prior to confirming success 
or failure. Each equipment type shall have passed a full hardware diagnostic 
test before the environmental tests are started. 

11.4.2.2 Environmental Test 

Environmental tests shall be performed one (1) time per on-board and outdoor 
equipment and shall be tested per SAE Recommended Practice J1455 JAN88, as 
follows: 

(a) Test 1 The Thermal Shock Test shall be per Section 4.1.3.2 of the 

aforementioned SAE Recommended Practice, and shall use the thermal profile 
portrayed in Figure 2C of said section, except that: 

i. The storage temperature limits shall be 25 to +150 degrees Fahrenheit. 
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ii. The presoak shall be 2 hours at 25 degrees Fahrenheit. 

iii. Hour 24 to hour 25 shall be at 70 degrees Fahrenheit. 

Functional tests shall occur immediately prior to and after the 25 hour test 
period. 

(b) Test 2 The Thermal Cycle Test shall be per Section 4.1.3.1 of the 
aforementioned SAE Recommended Practice, and shall use the thermal profile 
portrayed in Figure 2B of said section, except that: 

i. The temperature limits shall be 10 to +135 degrees Fahrenheit. 

ii. The chamber temperature shall be held for two (2) hours minimum at 
the 10 degrees Fahrenheit, followed by two (2) hours minimum at +135 
degrees Fahrenheit, followed by two (2) hours minimum at +70 degrees 
Fahrenheit. 

iii. Tests shall occur immediately prior to and every thirty (30) minutes 
during the test period, which will terminate at eight (8) hours 
minimum, provided that all conditions above are satisfied. 

(c) Test 3 The Humidity Test shall be per Section 4.2.3 of the aforementioned SAE 
Recommended Practice, and shall use the humidity profile portrayed in Figure 
3A, Recommended Humidity 8 Hour Cycle, of said section, except that: 

i. Temperature limits shall be 10 to +135 degrees Fahrenheit. 

ii. Humidity shall be 95% relative humidity (non-condensing). 

(d) Test 4 The Waterfront Test shall be conducted per an approved Waterfront 
Testing Plan to be prepared by the Contractor. No guidelines/standards 
currently exist for the testing of equipment to be used in an outdoor marine 
environment, such as that of the WSF. The Contractor shall prepare a 
comprehensive test plan, designed to demonstrate the operability of the 
equipment in the WSF environment, to be conducted at the WSF docks. This 
Test Plan shall be subject to the approval of the Contract Administrator and 
WSF. 

11.4.2.3 Electromagnetic Testing 

(a) Equipment shall be tested for electromagnetic compatibility per Section 6.III- 
1.7.1. 

(b) Equipment shall not sustain any permanent damage as a result of the exposure 
to electromagnetic fields nor shall it lose any data. 

(c) Testing shall take into account the conditions existing at Agency facilities 
including the radar emissions and radio transmissions from WSF ferry 
operations, as well as bus tunnel and trolley conditions. 

11.4.2.4 Radiated Electromagnetic Energy Test 

The Contractor shall identify requirements and demonstrate compliance with applicable 
Federal Communication Commission (FCC) regulations concerning conducted and 
radiated radio frequency energy. 
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11.4.2.5 Human Factors Test 


The human factors test shall verify that features and operating characteristics affecting 
the use of the RFCS by customers and Agency personnel are easy to understand, easy to 
use, and quick in response to customer and Agency personnel actions. The test shall be 
designed to evaluate items such as the following: 

(a) Time to perform a transaction. 

(b) Time to reset the device. 

(c) Time initialize the device from a complete power down. 

(d) Time to switch between various operating modes. 

(e) ADA compliance with regard to customer operation controls and 
instructions. The Contractor will provide a written statement prior to 
completion of Factory Acceptance Testing describing how the devices have 
been designed to comply with the ADA regulations and guidelines. 

11.4.3 Systems Integration Test 

The goal of Systems Integration testing is to connect each RFCS Subsystem and 
demonstrate the functionality as a fully integrated system prior to on site installation. 

11.4.3.1 System Integration Test Plan 

Contractor shall develop a System Integration Test Plan (CDRL 16) identifying how 
each subsystem is integrated such as communications, protocols, and data relationships, 
including any boundary conditions and security provisions. The Test Plan shall describe 
procedures to be followed for demonstrating the following, at a minimum: 

(a) Alarm transmission and all other device/component monitoring functions. 

(b) Data transmission, including all control functions, between devices and the 
DACS. 

(c) Data transmission between devices, DACS and Clearinghouse System. 

(d) Data integrity and security. 

(e) Credit and debit card transaction approvals and rejections (all types). 

(f) Check transaction approvals and rejections. 

(g) Funds reconciliation and settlement. 

(h) Report generation and transmission to Agencies. 

(i) Bad card rejections and lockout. 

(j) Auto revalue of cards. 

(k) Operating ranges for each type of equipment. 
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11.4.3.2 


(l) Performance measures. 

(m) Data encryption/security provisions for each type of data transfer. 

(n) All data transmissions shall be inspected for accuracy. Inaccurate data 
transmissions shall be recorded as a failure of the particular test for which the 
transmission was performed. 

(o) End-to-end scenario testing and business rule testing as specified in the 
accepted System Integration Test Plan (CDRL 16). 

(p) The procedures for handling maintenance (troubleshooting and 
correcting faults) and service functions shall also be written and demonstrated. 

(q) ADA compliance with regard to customer operation controls and 
instructions. 

(r) Facilitation of transit operator-customer interaction as a human factor. 

(s) The System Integration Test Plan shall also describe procedures for the 

Contractor to conduct a maintainability test that consists of introducing faults 
into the equipment and systems, and then measuring the time required for a 
technician to correct the fault. 

i) The Maintainability Test Plan (CDRL 15) shall show the basis of sample size 
selection and list of faults, including a reasonable time limit for repair 
performed by an average technician based on field experience, to be introduced 
into the equipment. This list shall represent every known failure mode for each 
unit of equipment and system, next to each fault, the Contractor shall identify. 

ii) The maintainability test shall be conducted in the following steps: 

a. The Contractor shall provide several units of the equipment to the 
Contract Administrator to simulate failed components, mis- 
adjustments, and incorrect settings. 

b. The simulated failures shall be introduced in proportion to their 
expected failure rate. 

c. The Contractor’s maintenance personnel shall be unaware of the 
simulated failures and shall be assigned to troubleshoot the equipment. 

d. The repair times shall be recorded and the mean-time-to-repair 
(MTTR) shall be compared with the advance list provided by the 
Contractor. 

iii) Maintainability Test results shall be reviewed and approved by the Contract 
Administrator. 

The System Integration Test Plan, including the Maintainability Test Plan, shall be 
submitted for the approval of the Contract Administrator a minimum of ninety (90) days 
prior to the commencement of System Integration Testing. 

System Integration Test Bed 

a. The Contractor shall provide a test-bed located in the Puget Sound Area. 
Each Agency equipment configuration shall be assembled in a single test-bed (“RFCS 
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test-bed”) to permit interconnection to simulate the overall RFCS. The RFCS test-bed 
shall be used to perform, among other things, device interface and integration testing, 
including systems integration. 

It is not required that the Central System or DACS which support financial and 
operational data processing be collocated at this site, but it must be possible to 
interconnect the test-bed equipment to them using the telecommunications processes to 
be used in the installed system environment. 

b. The test-bed shall be established prior to the commencement of System 
Integration Testing. Each Agency’s actual equipment shall also be utilized in the RFCS 
test-bed to perform end-to-end testing prior to delivery of said Agency equipment to 
Agency facilities. 

c. The Contractor shall be responsible for the test-bed environment until 
completion of Contract. 

The test-bed shall remain operational through the duration of the Contract and shall be 
supported by the Contractor and updated to reflect any changes to the devices, software 
and/or system configuration. 

11.4.4 Installation Test 

Installation Test shall occur any time a new unit of equipment is added on the site or an 
existing installed unit is exchanged. 

Upon verification of proper installation of the equipment, Contractor shall perform a 
complete post-installation operational test. 

(a) All functions of installed equipment at each location shall be tested under the 
supervision of Agency representative(s) to ensure operation of the equipment as 
specified. 

(b) An Installation Test Plan shall be submitted to the Contract Administrator a 
minimum of sixty (60) days prior to scheduled Installation Testing, and shall be subject 
to the approval of the Contract Administrator. 

(c) The Contractor shall inform the Contract Administrator, in writing, of any failures 
during Installation Testing. 

(d) The Contractor shall notify the affected Agency a minimum of seventy-two (72) 
hours, excluding weekends and holidays, prior to the scheduling of any Installation 
Tests at a particular site, and will not conduct any testing without RFCS and relevant 
Agency representation. 

(e) On thirty-five (35) days prior notice from the Contract Administrator, the 
Contractor shall provide, on site at Community Transit, a qualified software engineer to 
test and complete the integration of the DDU application described in 6.III-6.8.4. 
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11.4.5 System Commissioning 


Upon completion of Installation Testing, prior to the Beta Test and prior to Full-System 
Acceptance Testing, all system interfaces and integration functions shall be tested by 
the Contractor to verify proper operation of the installed RFCS as a whole: 

(a) The Contractor shall develop a System Commissioning Plan (CDRL 17) to 
demonstrate that all systems are fully operational prior to entering revenue service. 

(b) The System Commissioning Plan shall identify and describe all necessary tests to 
verify proper interfacing and installation of the equipment with other system facilities, 
including at a minimum: 

i. Schedule for system commissioning. 

ii. Commissioning test period. 

iii. Procedures for collecting and verifying data from each type of 
equipment. 

iv. Procedures for verifying the correct transfer of control commands to 
each type of equipment. 

v. Test reports content to be prepared. 

(c) The System Commissioning Plan shall be submitted to the Contract Administrator a 
minimum of ninety (90) days prior to scheduled System Commissioning Test, and shall 
be subject to the approval of the Contract Administrator. 

(d) The Contractor shall inform the Contract Administrator, in writing, of any failures 
during System Commissioning Testing. 

(e) The Contractor shall notify the affected Agency a minimum of seventy-two (72) 
hours, excluding weekends and holidays, prior to the scheduling of any System 
Commissioning Tests at a particular site, and will not conduct any testing without RFCS 
and relevant Agency representation. 

(f) System Commissioning Testing, as described herein and as specified by RFCS, shall 
be performed at the Agencies facilities. 

11.4.6 Beta Test 

The RFCS Beta Test shall demonstrate the same level of system functionality and the 
services to be provided for full RFCS rollout, and involving Agency personnel just as 
the full system would require, only on a smaller scale. The Beta Test shall involve the 
exercise of the small scale system under revenue service conditions. All functional 
requirements of the RFC system shall be tested. The estimated equipment quantities for 
each Agency for the Beta Test are listed in Appendix A. 

11.4.6.1 Beta Test Objectives 

The primary objectives of the Beta Test shall be to: 

(a) Validate that the system meets the functional, operational, and technical 
specifications of the fare card program as defined in the RFP under revenue operations. 
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(b) Ensure that the fare card technology, system design and implementation meet the 
internal needs of the individual Agencies in the Region for AFC systems and services, 
including any specific requirements or constraints with respect to physical 
implementation or operational processes. 

(c) Provide an assessment of, and field experience with, equipment reliability and 
maintenance requirements. 

(d) Provide an overall assessment of the program cost effectiveness and fiscal impact 
for each Agency. 

(e) Determine the appropriate scope of full rollout based upon the outcomes of Beta 
Test evaluation. 

11.4.6.2 Beta Test Settling In Period 

The initial period following commencement of revenue service in the Beta Test stage 
will be known as the Beta Test Settling In period. This period will provide a short time 
for the Contractor and the Agencies to correct minor implementation errors in advance 
of Beta Testing. The Beta Test Settling In period will consist of a minimum of ten (10) 
days. 

11.4.6.3 Changes to Agency Business Processes 

(a) The Contractor shall provide information to each Agency regarding each aspect 
of Beta test implementation, operation, and evaluation that impacts existing 
Agency operations. This information will be used by each Agency to update 
their business practices. At a minimum, impacts and required changes shall be 
identified in the areas of: 

i. Customer service 

ii. Revenue management and reporting 

iii. Ridership data management 

iv. Training 

v. Equipment installation 

vi. Equipment operation 

vii. Equipment testing and maintenance 

viii. Computer and network operations 

ix. Inventory and fare media management 

x. Public transportation operations 

xi. Marketing 

(b) Changes required to existing Agency business practices shall be identified a 
minimum sixty (60) days prior to the scheduled start of the Beta test. 
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11.4.6.4 Test Equipment, Documentation and Training 

All test equipment, documentation and training required for the Beta test shall be 
provided by the Contractor a minimum sixty (60) days prior to the scheduled start of the 
Beta test. 

11.4.6.5 Beta Test Plan 

(a) The Contractor shall prepare and submit a Beta Test Plan (CDRL 18) to the 
Contract Administrator for review and approval a minimum of ninety (90) days 
prior to the scheduled start of the Beta test. 

(b) At a minimum, the Beta Test Plan shall include: 

i. Schedule of all development, installation testing and implementation 
activities. 

ii. Description of proposed tests, procedures, recording methods, and test 
equipment per Section 6.II-11.4.8. Included in this shall be a series of 
control tests where specific transactions can be traced end-to-end 
through the system. 

iii. Contractor recommendations of fare cards and infrastructure elements 
required to meet the objectives of the Beta test. 

iv. Agency training and documentation. 

(c) The Agencies reserves the right to make changes to the Beta Test Plan as 
required and deemed necessary to meet and evaluate Beta test objectives. 

(d) The final Beta test infrastructure is subject to approval and confirmation by the 
Agencies. 

11.4.6.6 Certification of Beta Test Readiness 

Prior to beginning the Beta Test, the Contractor shall submit a Certification of Beta Test 
Readiness (CDRL 19) to the Contract Administrator. At a minimum, the Certification 
of Beta Test Readiness shall certify that: 

(a) The Contractor has completed and the Contract Administrator has accepted the 
Beta Test Plan and all related procedures; 

(b) The Contractor has submitted and the Contract Administrator has accepted all 
deliverables required to be submitted prior to conducting the Beta Test; 

(c) The Contractor has submitted and the Contract Administrator has accepted all 
required intellectual property documentation; 

(d) The Contractor has provided all training required to be conducted prior to 
beginning the Beta Test; 

(e) The Contractor has satisfied all applicable pre-test conditions imposed by this 
Contract or the accepted Beta Test Plan; 

(f) The Contractor has completed all applicable software coding; 
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(g) The Contractor has completed installation of all equipment to be used in the 
Beta Test; 

(h) All required systems are integrated, on-line, and ready for use; 

(i) The Contractor will conduct the Beta Test in complete conformity with the Beta 
Test Plan and the Contractor is aware of no matters which will adversely affect 
its ability to do so; 

(j) The Contractor is ready to begin the Beta Test immediately. 

The Contractor shall not commence the Beta Test until the Contract Administrator has 
issued a Notice of Apparent Completion for the Beta Test Readiness Milestone per 
Section 3.1-27.6. The Contractor shall promptly provide any documentation or 
information requested by the Contract Administrator to assist in the Contract 
Administrator’s review of the Certification or the Contractor’s state of readiness. 

11.4.7 Acceptance Test 

Acceptance testing shall be performed at a system level after the start of revenue 
service, with all components and subsystems completely functional, operational, on¬ 
line, and in service. 

(a) Acceptance testing shall be conducted by the Contractor in cooperation with Agency 
personnel and shall be subject to review and approval by the Agencies. 

(b) The RFCS will be installed in phases, acceptance testing of the equipment may also 
be conducted in phases. 

(c) Contractor may choose to group installed and commissioned equipment by Agency, 
by groups of Agencies, by equipment type across the entire system, according to start¬ 
up date, or other grouping approved by the Contract Administrator for acceptance 
testing purposes. 

(d) Reliability calculations for a particular equipment type in a group will remain 
consistent throughout the acceptance testing period. 

(e) Grouping of devices for Acceptance Testing shall be described in detail in 
Contractor’s Acceptance Testing Plan and shall be subject to Contract Administrator 
approval. 

(f) The Agencies reserve the right to make changes to the Acceptance Testing Plan to 
demonstrate conformance with the Contract requirements. 

(g) Acceptance requirements for equipment installed for WSF will be determined at the 
time of Implementation. 

11.4.7.1 Acceptance Testing Settling In Period 

The initial period of time following the completion of Phase II installation shall be 
designated as the Acceptance Testing Settling In period. 

(a) The Acceptance Testing Settling In period will last for at least thirty (30) days 
of revenue service prior to beginning Acceptance Testing. 
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(b) During the Acceptance Testing Settling In period a failure review test process 
shall be established (CDRL 20) by the Failure Review Team. 

(c) At the end of the Acceptance Testing Settling In period the Mean Transactions 
Between Failures (MTBF) for high transaction volume equipment of the same 
type shall be not less than 40% of the MTBFs presented in Division III for each 
type of RFCS equipment. 

(d) For equipment of the same type in a low transaction volume environment, the 
mean operating hours between failures (MOHBF) in a group shall be not less 
than 40% of the mean hours between failures presented in Division III for each 
type of RFCS equipment. 

(e) If at the end of the Acceptance Testing Settling In period the above MTBF and 
mean operating hours between failures (MOHBF) criteria are not met, then the 
reliability of the equipment shall be monitored until these criteria are met for 
thirty (30) consecutive days. 

(f) Acceptance testing shall not commence until the MTBF and MOHBF 
requirements in (c) and (d) above are met. 

11.4.7.2 Acceptance Test Plan 

Contractor shall develop a Acceptance Testing Plan (CDRL 21). 

(a) The plan shall be a comprehensive and detailed document, describing the 
management, monitoring, recording, and reporting procedures that will govern 
the acceptance testing period. 

(b) The Acceptance Testing Plan shall be submitted to the Contract Administrator 
for review and approval a minimum of ninety (90) days prior to the scheduled 
start of the Acceptance Test period. 

(c) The Agencies reserve the right to make changes to the Acceptance Testing Plan 
to demonstrate conformance with the Contract requirements. 

11.4.7.3 Acceptance Test Requirements 

At the end of the settling period, Acceptance Testing shall begin and shall be conducted 

over a minimum of one hundred and eighty (180) days under revenue service 

conditions. 

(a) The acceptance testing shall be conducted in three performance periods related 
to the reliability of the system. The MTBF and MOHBF requirements during 
the acceptance testing shall be incrementally increased from the settling period 
values in sixty (60) consecutive day periods as follows: 

i. 0-60 days: 60% of the MTBF and mean hours of operation between 
failures specified in Division III for each type of RFCS equipment. 

ii. 61-120 days: 80% of the MTBF and mean hours of operation between 
failures specified in Division III for each type of RFCS equipment. 

iii. 121-180 days: 100% of the MTBF and mean hours of operation 
between failures specified in Division III for each type of RFCS 
equipment. 
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(b) Each subsequent acceptance testing period shall not commence until the all 
requirements specified for the previous period of testing have been met. 

(c) During the Acceptance Testing period, chargeable failures shall be identified 
and recorded per Section 6.III-1.5.3. 

(d) Within fifteen (15) days following the completion of each period of Acceptance 
Testing, Contractor shall provide all testing data, documentation, reports, and 
all other related information to the Contract Administrator. 

(e) For any single group, if after sixty (60) consecutive days, the MTBF and 
MOHBF for that period has not been met, the acceptance testing shall continue 
beyond the sixty (60) consecutive days until the equipment has achieved the 
applicable reliability requirement. 

(f) Under no circumstances shall the acceptance testing for any group be allowed 
to proceed to the next sixty (60) consecutive day test period until the previous 
criteria has been met by that group. 

(g) For each group, the MTBF for high transaction volume devices for a given 
sixty (60) consecutive day period shall be derived by summing all the 
transactions for the sixty (60) consecutive day period for that group and device 
type and dividing by the number of chargeable failures recorded during that 
period for that group and device type. 

(h) If for any reason, a test period is not comprised of sixty (60) consecutive days, 
then the average MTBF shall be calculated by summing the transactions and 
chargeable failures for each individual test period, totaling not less than sixty 
(60) days of test data. 

(i) Should the equipment fail to meet the performance requirements as specified 
herein, Contractor shall make whatever improvements to the equipment and/or 
systems which are needed to meet the requirements. 

(j) Contractor shall continue to improve RFCS equipment and systems until the 
Contract requirements are met. 

(k) The Agencies reserve the right to limit the cut-over of the installed equipment if 
the acceptance test requirements are not being met. 

11.4.8 General Testing Procedures and Definitions 

11.4.8.1 General Procedures 

For each inspection and test, the Contractor shall: 

(a) Prior to testing or inspection, submit a detailed Test Procedure to the Contract 
Administrator for review and approval (CDRF 22) a minimum of thirty (30) 
days prior to conducting the test. 

(b) Provide check-off sheets for the items to be inspected, measurements to be 
taken, features required to be present, and the criteria required to be met. 
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(c) Be responsible for all Contractor, Supplier and Subcontractor inspections and 
tests to be performed, including those performed under the Contractor’s Quality 
Assurance plan. 

(d) Any and all hardware and software not passing inspections and/or tests and not 
meeting the approval of the Contract Administrator shall be repaired, replaced, 
and/or corrected by the Contractor and rescheduled for inspection and testing. 

(e) Receive approval from the Contract Administrator prior to proceeding with any 
tests or inspections. 

(f) Submit the final report to the Contract Administrator for review within thirty 
(30) days after completion of the inspection or test. 

(g) Retain all inspection and test results for a period of not less than two (2) years, 
during which the results shall be available for Agency review. 

(h) The Agencies reserve the right, at their discretion, to witness any or all 
inspections/tests, using Agency personnel and/or Consultants and agents. 

(i) In addition, the Agencies reserve the right to develop additional test procedures 
to be performed by the Contractor or other designated organizations. 

(j) The Contractor shall pay all Contractor-incurred travel, accommodation and 
living costs for the witnessing of inspections and tests. 

11.4.8.2 Test Plan 

The Contractor shall prepare a test plan and applicable procedures, that shall govern the 
conduct of activity, surveillance, direction, and methods of observing and recording the 
pertinent data. The Contractor shall provide an Overall Inspection and Test Plan (CDRL 
23) and specific Test Plans for each specific test. The Contract Administrator shall 
approve the test plan prior to proceeding with testing. As a minimum, the following 
elements shall be included in the test plan: 

(a) Dates, times and locations of testing. 

(b) Support and calibration tools and instrumentation to be used. 

(c) Technical publications to be referenced. 

(d) Spares and consumables to be available. 

(e) Maintenance facilities needed. 

(f) Staffing requirements to be met. 

(g) Scheduling of personnel. 

(h) The format and specific data to be collected during the test period together with 
the method used to report the test results. 

(i) Preventive maintenance tasks to be performed during the test. 
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11.4.8.3 Test Procedure Outline 


The test procedure shall include, as a minimum, the following: 

(a) Objective of test. 

(b) Test environmental conditions. 

(c) Detailed description of test specimens including drawings, part numbers, 
inspection and test records, maintenance records, and calibration records. 

(d) Detailed procedure of test. 

(e) Test equipment to be used, including any measuring equipment and/or any 
equipment aiding in the performance of the tests. 

(f) The level and schedule of preventive maintenance during the test. 

(g) Pass/fail criteria. 

(h) Retest procedure. 

(i) Test data sheet format. 

(j) Test notification to engineer. 

(k) Test reports. 

11.4.8.4 Test Tools and Logging 

At a minimum, the Contractor shall maintain the following capabilities: 

(a) Automated tools for measuring and capturing data packets and data flows at 
each major interface, from end to end, between subsystems. The test tools may 
include standard off the shelf communications software or customized in house 
trace and logging software. In the design review, the contractor shall propose a 
suite of tools and describe the methodologies for use. 

(b) Automated test tools shall be thoroughly documented in their use. 

(c) The test plan and procedures shall include the ability to automatically identify 
points of data corruption or transmission failure. 

(d) The reporting of test data must be made in English, and provide the ability to 
sort by time, event type and other key attributes, so that an end to end 
verification of data flows can be readily obtained. 

(e) Event log messages shall be logically grouped and labeled, fully parsed, and 
loaded into a database in a production manner, so that they are readily available 
for troubleshooting and analysis. 
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11.4.8.5 Test Reporting 


The Contractor shall provide a complete report documenting the operation and 
reliability during all acceptance testing. The report shall be in a form acceptable to the 
Contract Administrator. Test Reports are contract deliverables under CDRL 24. 

11.4.8.6 Test Failure Resolution 

The test procedures shall describe the process to be followed for the resolution of test 
problems, failure recurrence control, and general test conduct ground rules. 

11.4.8.7 Type I and Type II Failures 

11.4.8.7.1 Type I Failures 

A Type I failure is a malfunction resulting from conditions beyond the control of the 
Contractor, or failures that are minor in nature and quickly corrected. Type I failures 
may include: 

i. Power or communications outage. 

ii. “Jams” of mechanical equipment. 

iii. Accidents or mishandling. 

iv. Localized equipment failures. 

v. Test facility or instrument failure. 

The following shall apply to Type I failures: 

(a) Unless otherwise approved by the Contract Administrator, the test period shall 
be suspended for the time necessary to make the corrections, and testing shall 
resume starting at the time testing was suspended. 

(b) Time suspension shall begin when the failure is first noticed, and it shall extend 
only as long as required to correct the failure. 

(c) If a second Type I failure occurs in the same device, the Contractor shall 
provide evidence that the failures were distinct and unrelated in order to be 
classified as Type I. Final determination shall be made by the Failure Review 
Team per Section 6.III-1.5.3. 

11.4.8.7.2 Type II Failures 

A Type II failure is a malfunction that involves conditions within the control of the 
Contractor, failures related to the system design, or failures that may be of a minor or 
major nature that cannot be easily and quickly corrected. Type II failures include, but 
are not limited to: 

i. Two of the same Type I failures that occur after the first Type I failure has 
been corrected. 

ii. Three or more Type I failures (related or unrelated) in the same device. 

iii. Design deficiencies. 

iv. Software or firmware problems or recompilations. 

v. Failure to meet performance requirements. 
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Unless otherwise approved by the Contract Administrator, the test period shall be 
restarted to time zero after corrections are made. 


3.0 Other Terms and Conditions 

3.1 The Contractor waives and releases any and all claims arising out of, or related to, this Change Order, and 
all work and actual or constructive changes that occurred or began prior to the date of this Change Order, 
including, but not limited to, claims for equitable adjustment of time and compensation, delay, impact, overhead, 
or inefficiencies. 

3.2 Except as expressly amended by this Change Order, the Contract remains in full force and effect. All other 
provisions of the Contract not referenced in this Change Order No. 13 shall remain in effect unless modified in 
other executed Amendments and Change Orders. 
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Category 

Design Issue 
No 

RFI 

RFI Name 

Problem Statement 

Equipment 





CST 

186 



ERG to describe how card printing will work using 
existing photo files. 

CST 


RFCS 131 

Low-Tech Portable CST 

Portable CST employing a less sophisticated 
technical solution. 

CST 


RFCS 136 

CST - Electronic Check Readers 

CST check reader 

On-Board FTP 


ERG 263 

OBFTP Memory Expansion 

Additional memory for the On-Board Fare Transaction 
Processor. 

Portable FTP 


RFCS 110 

WSF Handheld Device 

ERG was requested to explore providing a single 
application for the Portable Fare Transaction 

Processor (P-FTP) for Washington State Ferries 
(WSF). This functionality would include a barcode 
reader. 

TRU 


RFCS 135 

TRU Configuration 

TRU configuration with internet communication 
solution 

TVM 

DR 107 

DR 107 

TVM Integration 

DR 107 TVM Integration is not complete 

ACCESS 





Non-PFTP Solution 

660 



KCM to prepare an RFI regarding process for 
providing RFCS information on rides on ACCESS paid 
for with regional or Institutional passes. 

Non-PFTP Solution 


RFCS 114 

KCM ACCESS - card-not- 
present 

To describe how KCM ACCESS fare collection shall 
operate in a card-not-present environment. 

Non-PFTP Solution 


RFCS 115 

KCM ACCESS - ridership data 

To describe how KCM ACCESS ridership reporting 
shall be performed 

Vanpool 





Institutional Agreements 


ERG 216 

Institutional Agreements & 

Van pools 

Addresses how institutional agreements handle 
vanpool fare payment. 

Non-PFTP Solution 

667 



ERG to investigate retail side of vanpool for CD. 

Non-PFTP Solution 

670 



Agencies to determine how to prevent double-dipping 
for vanpools in non-PFTP environment. 

Non-PFTP Solution 

138 



Need to finalize back-office integration & reporting for 
non-PFTP vans. Agencies to review ERG'S 
recommendations. 

Institutional Cards 





Agency Operator Cards 


RFCS 137 

Agency Operator Cards and 
Institutional Programs 

Describes how agencies will take advantage of the 
Institutional Program features of the system for their 
own employees & system operators. 

ACCESS Passes 


RFCS 140 

Institutions and ACCESS passes 

Pertains to an Institutions' ability to offer ACCESS 
passes within their subsidy programs 

KT Low-Income Riders 


RFCS 144 

Institutional Cards & KT Low- 
Income Riders 

Requests description for how KT Low Income card 
holders will participate in an Institutional Program. 

Operator Cards 
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Operator Cards 


ERG 246 

Operator Cards 

Describes the functionality required for the agencies 
to produce and manage Operator Cards, including 
costs (by option) and hardware requirements. 

Operator Cards 


RFCS 132 

Assignment of additional operator 
roles 

Within this RFI ERG has proposed a solution for 
meeting the requirement for assigning additional 
operator roles within the system. 

Website 





Institutional Program 


ERG 268 

KCM Institutional Program MOR 

ERG has not yet fully analyzed the impact of providing 
this functionality and would like to address post-FDR. 
Also ERG requests that all agencies agree that each 
Lead Agency will remain as Merchant Of Record 
regardless of payment mechanism. 

Card Registration 


RFCS 122 

Security & On-Line Registration 

The agencies request that ERG investigate alternative 
solutions for providing card registration (e.g., linking) 
via the RFCS web site that will not compromise 
system security 

Other 





Payment Methods 


ERG 260 

Commuter Bonus Vouchers 

Commuter Bonus Vouchers as a specific payment 
method 

Claims Processing 

8 

RFCS 077 

Automation of Claims Reporting 
process 

Need to provide impacts related to automating the 
claims process. 

Full Integration Mode 


RFCS 126 

KCM FIM 

Need to address how conversion from LIM to FIM will 
occur on KCM fleet. 
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